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M&GNo. 50037. 185US01 

SYSTEM AND METHOD FOR MANAGING CACHED OBJECTS USING 

NOTIFICATION BONDS 

Background of the Invention 

5 In many of today's distributed computing environment, it is often 

desirable to centrally maintain files that may be shared by multiple clients. A 
conventional distributed file system is typically used to facilitate the sharing of files. In 
such a system, a client may obtain access to a shared file by actively interacting with a 
file server that maintains the shared file. In particular, the client may obtain a file 

10 handle from the file server and may modify the file by communicating changes to the 
file server. Such a file sharing technique is commonly referred to as live sharing. 
Because large amount of communications between the file server and the clients is 
necessary for this type of file sharing, the resource overhead associated with live 
sharing can be very substantial. 

15 Currently, some distributed file systems allow clients to cache file data in 

the clients' computer memories. In particular, a client may store in its memory local 
copies of files and directories that are managed by a file server. These local copies 
facilitate file sharing by enabling the client to readily ascertain what files and directories 
are available on the server. However, the client must periodically contact the server to 

20 synchronize the cached file data in order to ensure that the data are up to date. 

Synchronizing cached file data is an expensive proposition, especially for a server with 
many clients that cache file data. For example, when a client reconnects with a server 
after a period of time of being disconnected, the client must synchronize the entire file 
data that are cached from the server because the client does not know which files or 

25 directories on the server were modified during the disconnection period. Because the 
work associated with synchronization is proportional to the number of files and 
directories that are cached, some systems limit the number of files and directories that 
each client is allowed to cache. 
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Recently, the mobile computing environment has become increasingly 
popular. In such an environment, mobile clients can often be disconnected from the 
network for an extended period of time. This poses a special challenge for distributed 
file systems. For example, the required synchronization cannot occur while the mobile 
5 clients are not connected to the network. In addition, users increasingly want clients to 
cache a substantial portion of server files and directories. These cached data must be 
synchronized when the mobile clients are reconnected to the network. Synchronizing of 
this large amount of data requires a significant amount of client/server communications 
and computing resources, a situation that is prohibitive in many applications. 
10 An effective and efficient method for caching files by clients in a 

distributed file system eludes those skilled in the art. 

Summary of the Invention 

Briefly stated, the present invention provides a system and method for 
managing cached objects using notification bonds. In one aspect, the invention is 

1 5 directed to a computer-implemented method for a client to interact with a server using 
notification bonds. The server manages an original object. The client creates a cached 
object from the original object and establishes a notification bond with the server. The 
notification bond enables the client to obtain a notification from the server in response 
to an object related event associated with the original object. 

20 In another aspect, the invention is directed to a computer-implemented 

method for a server to interact with a client using notification bonds. The server 
establishes a notification bond with the client. The server enables the client to cache the 
object and provides notifications to the client when an object related event occurs. 

In still another aspect, the invention is directed to a distributed file 

25 system for sharing objects using notification bonds. The distributed file system 

includes a server configured to manage original objects. The server includes a bond 
manager configured to issue notification bonds to clients. The distributed file system 
may also include a client configured to create cached objects associated with the 
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original objects. The client includes a notification handler configured to maintain 
notification bonds associated with the original objects in conjunction with the server. 

Brief Description of the Drawin2S 

FIGURE 1 is a schematic diagram of an exemplary cached objects 
5 management system that implements the present invention; 

FIGURE 2 is a schematic diagram of notification handler and a bond 

manager; 

FIGURE 3 is a schematic diagram of exemplary communications 
between a client and a server in a cached objects management system; 
10 FIGURE 4 is a schematic diagram of an exemplary filter table; 

FIGURE 5 is a schematic diagram of an exemplary server bond table; 

FIGURE 6 is a schematic diagram of an exemplary client bond table; 

FIGURE 7 is an operational flow diagram of a process for a client to 
establish a notification bond with a server for an object that is managed by the server; 
15 FIGURE 8 is an operational flow diagram of a process for a server to 

establish a notification bond with a client for an object; 

FIGURE 9 is an operational flow diagram of a process for a server to 
send a notification to a client; 

FIGURE 10 is a schematic diagram of a process for a client to 
20 synchronize its cached objects with a server 

FIGURE 1 1 is a schematic diagram of a process for a client to drop a 
notification bond; 

FIGURE 12 is a schematic diagram of a process for a server to drop a 
notification bond; in accordance with embodiments of the invention. 

25 Detailed Description of the Preferred Embodiment 

The inventors of the present invention have determined that a distributed 
file system that enables clients to efficiently and effectively cache objects managed by a 
server will greatly improve the system's object-sharing performance. The inventors 
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have also appreciated that enabling a client to rapidly determine which objects on the 
server were modified while the client was offline will significantly reduce the work 
associated with revalidating the client's cached objects. Thus, the present invention 
focuses on a system and method for managing cached objects using notification bonds. 
5 The manner in which cached objects are managed by the present invention is very 
different from conventional file-caching methods. For example, some conventional 
methods demand each cached file to be updated on a per item basis. These methods 
require a significant amount of file management resources and can lead to the release of 
stale cached files to applications and users. Other conventional methods require all of 

10 the cached files to be synchronized by comparing them with the corresponding files on 
the server. Synchronizing the entire cache content by comparison causes a significant 
performance load on clients, the server, and the network. These problems are 
exacerbated by techniques to leverage cache states while the client is disconnected from 
the server, since it is not possible to revalidate while being offline. 

15 In contrast, the present invention enables a client to quickly determine 

which objects on a server have been changed relative to the corresponding cached 
objects and to efficiently synchronize those cached objects to match the changed 
objects. For an object that is cached by the client, a notification bond associated with 
the object is established. The notification bond enables the client to be notified of 

20 changes that were made to the object. The client and the server keep states associated 
with the notification bond. These notification bond states are typically stored in 
persistent memory, which enables the client and the server to reestablish theses states 
after a restart or reboot. These states allow the client to bring the cached object up to 
date without having to revalidate all of the other cached objects. These and other 

25 aspects of the invention will become apparent after reading the following detailed 
description. 

FIGURE 1 is a schematic diagram of an exemplary cached objects 
management system 100 that implements the present invention, in accordance with one 
embodiment of the invention. In other configurations, cached objects management 
30 system 100 may include more or less components than those shown. As shown in the 



figure, cached objects management system 100 includes components on server 103 and 
clients 121-123. 

Server 103 is a computing device that is configured to manage objects 
and facilitate sharing of the objects for clients 121-123. Server 103 may include one or 
5 more computers. Each computer is typically configured with a memory, which may 
include computer-readable media, such as RAM, ROM, hard drives, optical drives, etc. 
In this embodiment, the memory includes a bond manager 105, file system manager 107 
and original objects 109. File system manager 107 is a software component of file 
server 103 and is configured to handle original objects 109 for server 103. An example 

10 of file system manger 107 is NTFS developed by Microsoft. Original objects 109 are 
data structures stored in server 103 that may be shared by clients 121-123. Original 
objects 109 may be any type of data structures, such as file directories, any kind of files 
such as executables, data, etc. Original objects 109 are typically stored in mass data 
storage units such as hard drives. In such mass data storage units, an object may be 

15 identified by its storage location in the hard drive, such as volume ID, file ID, file path, 
etc. 

Bond manager 105 is a software component of server 103 and is 
configured to notify clients of changes to objects that are cached by the clients. Bond 
manager 105 may be integrated as part of another component such as file system 

20 manager 107 or may be implemented as a separate component, such as a filter. Bond 
manager 105 is configured to coordinate with notification handlers 131-133 to keep 
cached objects 141-143 up to date. Bond manager 105 will be discussed with more 
detail in conjunction with FIGURE 2. Briefly stated, bond manager 105 establishes 
notification bonds with notification handlers 131-133 for providing notifications 

25 associated with cached objects 141-143. The notifications enable clients 121-123 to 
determine which cached objects 141-143 need to be updated. 

Server 103 is configured to communicate with clients 121-123 through 
network 1 10, which may be any type of network such as the Internet or any wide area 
network (WAN), local area network (LAN), wireless network, etc. Communications 

30 between server 103 and clients 121-123 will be discussed in detail in conjunction with 
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FIGURE 3. Briefly stated, server 103 is configured to communicate with clients 121- 
123 for establishing bonds, sending notification, and synchronizing cached objects 141- 
143, etc. Communications between clients and server are considered computer-readable 
media. 

5 Clients 121-123 are computing devices that are configured to access 

objects from server 103. Clients 121-123 may interact with the server 103 with an 
active communication connection. Clients 121-123 may also function without a 
connection with server 103. Clients 121-123 are configured to enable users to work 
directly on them or to serve as a server for other computing devices. Each of the clients 

10 121-123 is configured with a memory, which may include any type of computer- 
readable media. The memories of the clients 121-123 include cached objects 141-143 
and notification handlers 131-133. Cached objects 141-143 are replicated from original 
objects 109 that are useful to clients 121-123. Cached objects 141-143 may not be 
synchronized with their corresponding original objects 109 on server 103 if the 

15 connections between clients 121-123 and server 103 are not established or are lost. To 
be useful to clients 121-123, cached objects 141-143 should be synchronized with the 
corresponding original objects 109. With this invention, clients 121-123 may 
synchronize cached objects 141-143 using notifications corresponding to the objects. 

Notification handlers 131-133 are components of clients 121-123 that 

20 handle the communications and data management related to notifications. Notification 
handlers 131-133 will be discussed in detail in conjunction with FIGURE 2. Briefly 
stated, notification handlers 131-133 are configured to establish notification bonds with 
server 103 and to handle notifications and cached object synchronization for 
clients 121-123. 

25 FIGURE 2 is a schematic diagram of notification handler 131 and bond 

manager 105, in accordance with one embodiment of the invention. In this 
embodiment, bond manager 105 includes a filter component 205 and a service 
component 210. Filter component 205 is configured to scan object related events 
incoming to and outgoing from the file system manager of server 103. These object 

30 related events may involve objects that are cached by clients, such as client 121. Bond 



manager 105 maybe configured to create notifications for client 121 in response to 
these events. Filter component 205 is configured to determine which object related 
events require notifications using a filter table 207 and to forward these events to 
service component 210. The filter table 207 identifies objects that require notifications. 
5 An exemplary data structure of filter table 207 will be discussed in detail in conjunction 
with FIGURE 4. 

Service component 210 is configured to establish notification bonds with 
clients for receiving notifications regarding changes in objects that are cached by the 
clients. In this embodiment, service component 210 maintains a server bond table 215 

1 0 that includes states associated with the notification bonds. Server bond table 2 1 5 
identifies objects that require notifications and includes the states that enable server 
component 210 to create notifications for clients. The notifications may be provided to 
clients in a number of different ways. In one embodiment, service component 210 is 
configured to maintain notification logs 217 that contain notifications for notification 

1 5 handler 131. One configuration of this embodiment includes configuring service 
component 210 to enable notification handler 131 to retrieve notification logs 217. 
Another configuration includes configuring service component 210 to send notification 
logs 217 to notification handler 131 in response to an event, such as the expiration of a 
pre-determined time period, the size of notification logs 217 exceeded a threshold value, 

20 etc. 

In another embodiment, notification handler 131 maybe configured to 
send notifications to notification handler 131 when an active communication link is 
available. Notification handler 131 may be configured to record notifications in 
notification logs 217 when an active communication link is not available and to provide 
25 notification logs 217 to notification handler 131 when the communication link is 
reestablished. 

Notification logs 217 may be logically implemented in many ways. In 
one embodiment, notification logs 217 are implemented as a multiplexed log such that 
notifications for multiple clients may be included in the log. In another embodiment, 
30 notification logs 217 are implemented as per-client logs so that each client has a 



separate notification log. Service component 210 may maintain a log table 224 that 
includes data for identifying which portions of a multiplexed log are associated with a 
particular client or which per-client log is associated with the client. Service component 
210 may be configured to send or make available the entire notification logs 217 or only 
5 the portion of the logs that applies to client 121. Relevant data in notification logs 217 
may be used by notification handler 131 to bring the cached objects of client 121 up to 
date. 

Service component 210 is also configured to determine whether a client 
that made changes to an object has a notification bond on the object and to avoid 

10 creating a notification for that client. Service component 210 may make the 

determination by discovering a client identifier in the data related to an object change 
event and matching the client identifier with the ones in a client table 223, which 
contains identification information for each client that is associated with a notification 
bond. Service component 210 may also be configured to provide and update filter table 

15 207 for filter component 205. 

Notification handler 131 is configured to interact with bond manager 105 
to establish notification bonds on objects that are cached by client 121. In this 
embodiment, notification handler 131 maintains a client bond table 220 that includes 
states associated with established notification bonds. Client bond table 220 will be 

20 discussed in more detail in conjunction with FIGURE 6. Briefly stated, client bond 
table 220 includes states about notification bonds that have been established on one or 
more servers. Ideally, the states in client bond table 220 should match the 
corresponding data in server bond table 215. However, the states may not be the same 
due to disconnects and crashes. On reconnection, the client and the server will re- 

25 synchronize the states. Synchronizing the states in the tables may serve to revalidate 
the cached objects in client 121. 

FIGURE 3 is a schematic diagram of exemplary communications 300 
between a client and a server in a cached objects management system, in accordance 
with one embodiment of the invention. Communications 300 may occur through a 

30 session that the client opened on the server. For illustrative purpose, the 



communications are shown to be between server 103 and client 121. However, in 
operation, the communications are actually between software components of a server 
and a client, such as between notification handler 141 and bond manager 105. 

Communications 302 relate to acquiring notification bonds and include 
5 messages 305 and 310. As shown in the figure, client 121 may acquire a notification 
bond by sending a message 305 with a notification bond request. The notification bond 
is associated with an object managed by server 103 and cached by client 121. The 
notification bond enables client 121 to obtain notifications about file system events that 
relate to the modification of the object. Message 305 includes an identifier that 

10 identifies the object. The identifier may contain information about the file path of the 
object on server 103. Message 305 may also include the type of notification bonds that 
is desired. Each type of bonds may specify the data to include in the notifications. 

In response to message 305, server 103 may establish a notification bond 
and send a message 310 with the notification bond to client 121. Message 310 may 

15 include states related to the notification bonds, such as a bond number (BN) that is 

uniquely associated with bond and a server aggregate bond number (ABN), which is a 
monotonically increasing number that is unique to client 121 with respect to server 103. 
Both server 103 and client 121 maintain an ABN. Comparing the client ABN and the 
server ABN enables client 121 and server 103 to determine whether there are missing 

20 bonds. 

Communications 322 relate to providing notification to client 121 with a 
client pull configuration and include messages 325 and 330. In the client pull 
configuration, client 121 is configured to retrieve notifications in a notification log from 
a server 103. Client 121 may send message 325 that includes a request for a 

25 notification log associated with the notification bond. The notification log may include 
notifications associated with multiple notification bonds. In response, server 103 may 
send message 330 that includes the notification log. The notification log contains 
notifications for client 121 created in accordance with the notification bond. After 
receiving the notification log, client 121 may use the notifications in the notification log 

30 to update the cached object. 



Communications 330 relate to providing notification to client 121 with a server push 
configuration and include messages 334 and 336. In response to a file system event 
related to the modification of an object with a notification bond, server 103 determines 
a notification and sends message 334 with the notification to client 121. Message 315 
5 may include a BN that identifies the object. Message 334 may also include data about 
the modification so that client 121 may update the corresponding cached object without 
additional communications with server 103. In response, client 121 may send message 
336 to server 103 with an acknowledgment. 

Communications 340 relate to providing notifications to client 121 in 

10 response to a reconnect operation and include messages 334 and 336. As part of the 
reconnect operation, client 121 may send message 342 that includes a request for a 
notification log associated with the notification bond. In response, server 103 may send 
message 344 that includes the notification log. Server 103 may send message 346 that 
includes states of the notification bonds that it has for client 121. Client 121 may use 

15 these states to discover notification bonds that are missing on the client and server 103 
and to reacquire or reestablish the missing notification bonds. In response, client 121 
may send message 348 that includes an acknowledgment. 

FIGURE 4 is a schematic diagram of an exemplary filter table 207, in 
accordance with one embodiment of the invention. Filter table 207 enables a bond 

20 manager to determine which object is associated with a notification bond when the bond 
manager scans object-related events. As shown in the figure, filter table 400 is a data 
structure indexed by object identifiers, such as object identifiers 411-414. Object 
identifiers 411-414 may be file names or directory names, paths, hash of the names or 
path, or any other identifying values. Each of the object identifiers identifies an object 

25 and indexes an entry associated with the object. The entry may include a variety of data 
associated with the object. In this embodiment, the entry includes a Boolean identifier 
that indicates whether the object is associated with a notification bond. In another 
embodiment, filter table 207 may be simplified by only including object identifiers of 
objects that are associated with a notification bond. As shown in FIGURE 4, object 
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identifiers 41 1-414 identify Objects P, Q, R and S and the entries indicate that Objects 
P, Q and S are associated with notification bonds. 

FIGURE 5 is a schematic diagram of an exemplary server bond 
table 215, in accordance with one embodiment of the invention. Server bond table 215 
5 is a data structure maintained by a bond manager in a server for managing notification 
bonds. As shown in the figure, server bond table 215 is indexed by object identifiers, 
such as object identifiers 511-513. Each of the object identifiers identifies an object and 
indexes entries associated with the object, such as entries 520. Entries 520 may include 
client identifiers 541-543 that associate their corresponding entries with a particular 

10 client, bond numbers 53 1-533 that uniquely identify notification bonds, and bond type 
identifiers 551-553 that identify the type of notification bonds associated with their 
corresponding entries. As shown in FIGURE 5, bond table 215 includes object 
identifier 511 that identifies Object P. Entries 520 indicate that Clients a, b, and c have 
notification bonds associated with Object P. 

1 5 FIGURE 6 is a schematic diagram of an exemplary client bond 

table 220, in accordance with one embodiment of the invention. Client bond table 220 
is a data structure maintained by a notification handler in a client for managing 
notification bonds. As shown in the figure, client bond table is a data structure indexed 
by server identifiers, such as server identifiers 61 1-612. Server identifiers 611-612 

20 identify servers that have notification bonds with the client. As shown in the figure, 

server identifier 611 identifies server Rll, which is associated with ABN identifier 615, 
offset 617, and entries 620. 

ABN identifier 615 identifies an aggregate bond number associated with 
server Rl 1. The aggregate bond number is monotonically increasing and enables the 

25 client to determine whether there are missing notification bonds. Offset 617 may be 
used to identify the last location in a notification log where notifications are received 
from a particular server. Offset 617 enables the client to commit after receiving 
notification from a server. This prevents the client from having to parse through an 
entire notification log on a server even when the notification log may include 
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notifications that the client has already received. Offset 617 may be a pointer to a per- 
client notification log or a multiplexed notification log. 

Entries 620 contain data that enable the client to manage notification 
bonds and to update the cached objects associated with the notification bonds. In this 
5 embodiment, the entries include object identifiers 641-643 and bond numbers 631-633. 
Object identifiers 641-643 identify the cached objects corresponding to the notification 
bonds. File paths for the cached objects may be encoded in object identifiers 641-643. 
Each of the bond numbers 631-633 uniquely identifies a particular notification bond 
between the client and server Rl 1 . 

10 FIGURE 7 is an operational flow diagram of a process 700 for a client to 

establish a notification bond with a server for an object that is managed by the server, in 
accordance with one embodiment of the invention. The process may be implemented 
whenever the client caches an object or may require separate initiation by the client. 
Moving from a start block, process 700 moves to block 710 where a request is sent from 

1 5 the client to the server for a notification bond. At block 7 1 5 , the notification bond is 
received from the server. The notification bond may include a bond number (BN) that 
uniquely identifies the notification bond. The notification bond may also include access 
information such as the file path of the object associated with the notification bond. At 
block 720, the client adds an entry to a client bond table. The entry contains data about 

20 the notification bond. At block 725, the client updates the aggregate bond number 
(ABN) associated with the server. In this embodiment, the ABN is the BN of the 
notification bond. At block 730, the client caches the object associated with the 
notification bond in memory. Process 700 then ends. 

FIGURE 8 is an operational flow diagram of a process 800 for a server 

25 to establish a notification bond with a client for an object, in accordance with one 

embodiment of the invention. The process may be implemented when the client request 
to cache an object or in response to a separate initiation by the client. 

Moving from a start block, process 800 moves to block 810 where a 
bond request is received from the client. At block 815, a notification bond is 

30 established. At block 820, an entry is added to a server bond table. An entry may also 

12 



be added to a filter table. At block 825, the ABN unique to the client is updated. At 
block 830, the notification bond is sent to the client. Then, process 800 ends. 

FIGURE 9 is an operational flow diagram of a process 900 for a server 
to send a notification to a client, in accordance with one embodiment of the invention. 
5 Moving from a start block, process 900 continues at block 910 where an object related 
event associated with an object is determined. At decision block 915, a determination is 
made whether notification is required for the notification event. This determination 
may be made by checking whether the object is referenced in a filter table. If 
notification is not required, the process ends. 

10 Returning to decision block 91 5, if notification is required for the object- 

related event, process 900 continues at block 920 where one or more notification bonds 
associated with the object are determined. The determination may be made by checking 
entries in a server bond table. There could be more than one notification bond because 
multiple clients may have cached the object and obtained a notification bond. The 

1 5 process as described below is applicable for each client that has a notification bond. 

At decision block 923, a determination is made whether the object 
related event was caused by the client with a notification bond on the object. If so, the 
client already knows about the object related event and no notification is sent to that 
client. If that client is the only client with a notification bond, process 900 ends. 

20 Otherwise, the process continues at block 925. 

Returning to decision block 923, if the object related event was not 
caused by any client with a notification bond on the object, process 900 moves to block 
925. At block 925, notifications are created based on data in the server bond table. 

At decision block 930, a determination is made whether to send the 

25 notification to the client. This determination is not necessary if the server is configured 
to record all notifications in notification logs. However, if the server is configured to 
send notifications directly to clients under certain conditions, the determination is 
positive if those conditions exist. The determination may become negative if a 
disconnect occurred while a notification was being sent. 
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If the determination is positive, process 900 moves to block 935 where a 
notification is sent to each of the clients and ends. Returning to decision block 930, if 
the determination is negative, the notification associated with that client is sent to a 
notification log. Blocks 935 and 940 may both execute and may apply to multiple 
5 clients. Process 900 then ends. 

FIGURE 10 is a schematic diagram of a process 1000 for a client to 
reconnect to a server, in accordance with one embodiment of the invention. Process 
1000 may be automatically implemented by the client upon reconnecting to the server 
after a period of being disconnected. Process 1000 may also be implemented in 

10 response to a separate initiation by the client, or to an external event, such as prompting 
by the server when the size of a notification log reaches a pre-determined value. 
Moving from a start block, process 1000 continues at block 1020 where the client and 
the server are mutually authenticated. At block 1025, the notification bonds on the 
client and those on the server are compared to ascertain whether there are missing 

1 5 notification bonds. Notification bonds may be missed if data about the notification 
bonds were lost due to system crashes or other failures. In one embodiment, the 
comparison is made by comparing the client ABN with, the server ABN. 

At decision block 1030, a determination is made whether there are 
missing notification bonds on the server. The client ABN being larger than the server 

20 ABN is an indication that there are missing notification bonds on the server. For 

example, if the client asserts notification bonds represented by BNs that are larger than 
the ABN asserted by the server, the notification bonds asserted by the client are the ones 
about which the server does not know. 

If there are missing notification bonds, process 1000 continues at block 

25 1050 where the missing notification bonds are reacquired from the server. For 

example, the client may initiate process 700, previously discussed in conjunction with 
FIGURE 7, to reacquire the notification bonds. The client may also discard those 
notifications bonds and the cache objects associated with them. The process continues 
at block 1040. 
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Returning to decision block 1030, if there are no missing bonds on the 
server, process 1000 moves to block 1040 where a determination is made whether there 
are missing bonds on the client. The client ABN being smaller than the server ABN is 
an indication that there are missing notification bonds on the client. For example, if the 
5 server asserts notification bonds represented by BNs that are larger than the ABN 
asserted by the client, the notification bonds asserted by the server are the ones about 
which the client does not know. If there are no missing bonds on the client, the process 
ends. If there are missing notification bonds on the client, process 1000 continues at 
block 1045 where the client bond table is updated to remove those missing notification 

10 bonds. The client may also cache the objects associated with the missing notification 
bonds or discard the bonds. The process then ends. 

FIGURE 1 1 is a schematic diagram of a process 1 100 for a client to drop 
a notification bond, in accordance with one embodiment of the invention. Process 1 100 
may be implemented by a client to drop one or more notification bonds. For illustrative 

15 purpose, process 1 100 will be described in the context of dropping a single notification 
bond. Moving from a start block, process 1 100 goes to block 1 120 where a 
determination is made to drop a notification bond. The client may wish to drop a 
notification bond for a number of reasons. For example, if a client has determined that 
there is no further need for a particular cached object, the client may delete the cached 

20 object and drop the associated notification bond. At block 1 125, the client performs 
operations for dropping the notification bond. For example, the client may delete data 
associated with the notification bond from the various tables for implementing the 
notification bond. At block 1 130, the client sends a request to the server for dropping 
the notification bond. To maintain consistency, the client may perform the operations 

25 in block 1 125 to commit to dropping the notification bond before sending a drop request 
to the server in block 1 130. In response, the server may send an acknowledgment to the 
request, as shown in block 1135. The process then ends. 

FIGURE 12 is a schematic diagram of a process 1200 for a server to 
drop a notification bond, in accordance with one embodiment of the invention. Process 

30 1200 may be implemented by a server to drop one or more notification bonds. Moving 
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from a start block, process 1200 goes to block 1220 where a determination is made to 
drop a notification bond. The server may wish to drop a notification bond for many 
different reasons. For example, if the server has stopped managing an object, the server 
may drop notification bonds associated with that object. The server may drop 
5 notification bonds associated with a particular client if that client has not contacted the 
server for an extended period of time. 

At decision block 1225, a determination is made whether all notification 
bonds associated with a particular client are being dropped. If not, process 1200 
continues at block 1229. At block 1229, the server performs operations for dropping 

10 the notification bond. The process then moves to block 1230. 

Returning to decision block 1225, if all notification bonds associated 
with the particular client are being dropped, the process goes to block 1227 where the 
ABN associated with the client is set to 0. Process 1200 continues at block 1228 where 
the server performs operations for dropping all notification bonds associated with the 

15 client. The process then moves to block 1230. 

At block 1230, the server provides a notification to the client about 
dropping a particular notification bond or all of the client's notification bonds. The 
notification may be provided by recording the notification in a notification log. To 
maintain consistency, the client may perform the operations in block 1228 or block 

20 1229 to commit to dropping the notification bonds before sending a notification to the 
client in block 1230. The server may receive an acknowledgment from the client, as 
shown in block 1235. The process then ends. 

In conclusion, the present invention enables clients to cache a large 
number of objects and rapidly synchronize the cached objects with the corresponding 

25 objects on a server. The capacity and the efficiency of the present invention is achieved 
in part by enabling the clients to know which cached objects were modified on the 
server and required to be updated. Notification bonds are used to ensure that changes 
made to objects that are cached are communicated to the clients. Persistent shared 
notification bond states enable the server and the clients to reestablish the notification 

30 bonds to survive a restart and reboot of the clients and the server. The present invention 
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also minimizes traffic in situations where a client is only interested in caching a fraction 
of the content in a server. 

The above specification, examples and data provide a complete 
description of the invention. Since many embodiments of the invention can be made 
5 without departing from the spirit and scope of the invention, the invention resides in the 
claims hereinafter appended. 
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